test(token-2022/transfer-fee): assert fee config, balances and withheld amounts - #730
Open
moviendome wants to merge 2 commits into
Open
Conversation
…ld amounts The suite runs the full fee lifecycle but never reads anything back: six specs log a signature and the seventh mints and checks nothing, so it would pass with the fee at zero, the cap ignored, or the whole transfer withheld. Read the mint and token accounts after each step and assert the numbers the fixture implies: the TransferFeeConfig after initialize, sender and recipient balances and withheld amounts after each transfer (the second proving maximumFee caps 1% of 200 at 1), the withheld amount moving to the mint on harvest and to the sender's account on withdraw, and the updated fee scheduled two epochs out with the old one still in force. Reads use @solana/spl-token helpers already in the dependency set.
Contributor
 |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
…e update The activation epoch was compared against an epoch read after the transaction, which could roll over between execution and the read. Read it before and after and accept either, so the assertion cannot flake on an epoch boundary.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
tokens/token-2022/transfer-feeruns the full fee lifecycle — initialize, mint, two transfers, harvest, withdraw, update — but never reads anything back. Six specs log a transaction signature and the seventh mints and checks nothing, so the suite passes with the fee at zero, the cap ignored, or the whole transfer withheld. The spec titled "fee limit by maximumFee" does not look atmaximumFee.This reads the mint and token accounts after each step and asserts the numbers the fixture implies (decimals 2, 100 bps,
maximumFee = 1, 300 minted):withheldAmountis 0, older and newer fee are 100 bps / max 1withheldAmount2withheldAmount0, sender holds 2epoch + 2, older fee still 100 bps / max 1Reads use
getMint,getAccount,getTransferFeeConfigandgetTransferFeeAmountfrom the@solana/spl-tokenversion already in the dependency set. No new dependencies; lockfile unchanged. Test bodies and the existing log lines are untouched; the assertions are appended to each spec.Test plan
anchor testat this commit: 7 passing.maximumFeeto 3 in the initialize spec and rerun. The first transfer still passes (the cap is not reached at 100), then 4 failing: the cap spec (expected 297n to equal 298n), harvest and withdraw (3nvs2n), and update (3nvs1n). Restored to 1, back to 7 passing.pnpm check(prettier) clean.AI use
I identified the gap while reading this example, chose the assertions and the expected numbers, and reviewed the diff and both test runs; Claude drafted the code and this description.
🤖 Generated with Claude Code